We have all seen some variant of the famous Sidney Harris cartoon – two people standing at the chalkboard, an incredibly complex series of equations or process flow on the left, a simplification or result on the right, and the words “then a miracle occurs” in the middle. It’s an amusing depiction and a tempting approach. In fact, I suspect most of us wanted to use this at one point or another in our mathematics courses. As much as we laugh about the cartoon and critique others for taking this approach, the sad fact is many systems practitioners frequently fall into the trap of “then a miracle occurs” in two critical stages of our systems engineering endeavors.
The first miracle in systems engineering is where requirements come from. We invest a great deal of time and effort in improving the way we write requirements. For example, INCOSE has an excellent Guide for Writing Requirements that discusses the characteristics of good requirement statements and good requirement sets – absolutely necessary but certainly not sufficient. The initial derivation of the need – where the requirements come from – is often murky beyond the rationale for individual requirements, and there may be a shorthand for the approach (“market study,” “focus groups,” “ConOps,” etc.). The problem with each of these is the untold story, the context of the problem, the process and the individuals, the combination of which contains the needed richness to understand the true needs underlying the imperfect representation in requirements.
Henry Ford famously said, “If I had asked people what they wanted, they would have said faster horses.” Even those trained in the characteristics of good requirements state needs in the context of the mental models they know. This is why the technique of asking the five whys, of gently and progressively probing the basis behind a requirement statement, is so critical. The five whys help us strip away solution, assumption, symptoms, and more as we seek the real statement of need and desire. While this is an essential tool in every systems engineer’s toolbox, there is a better way.
If we are simply given requirements, the best we can do is attempt to recreate the greater context and intent of the customers, users, and stakeholders. The better way is to lead them through a process that exposes and communicates the context, their mental models, and their rationale on their journey to requirements – to simply remove “then a miracle occurs” from the definition of need. This is the purpose behind model-based conceptual design (MBCD) which takes the fundamental ideas of model-based systems engineering (MBSE) and applies them to the requirements definition phase. The reasoning is simple. If we wish to improve our systems engineering results, we should focus on the quality of the initial requirements, ensuring that they are accurate and complete representations of the true desires rather than symptoms of desires or shadow requirements limited by assumptions.
The “miracle occurs here” curtain
How does MBCD draw back the “miracle occurs here” curtain and have that result in better requirements? It enhances the quality of expression and communication by moving from low fidelity representations to higher fidelity, richer representations of ideas complete with their context. Exposing the context – to others involved during requirements definition and to those who later interpret the requirements – completes the picture and minimizes miscommunication. As Scott McArthur illustrated during the 2014 INCOSE International Symposium, ask someone to visualize a brown dog in a yard and most will picture a pet in front of a house. Add the context of a British pub and you may have a completely different picture – three feet of ale.
Exposing context, thinking, and rationale during the requirements phase helps ensure we are solving the right problem. It improves the effectiveness of validation early in the process before analysis and engineering of the solution system even begins. Done well, it also highlights competing prioritizations and considerations between various stakeholders and establishes a reasoned basis for making tradeoffs between capabilities, characteristics, cost, and schedule during the project.
Using MBCD to derive better requirements removes our reliance on the first miracle from our systems engineering journey. We then need to remove the expectation of a second miracle – how we move from the requirements to the architectural solution itself.
Removing the second miracle
I have argued many times that the purpose of systems engineering is not to produce specification or build models or even follow process, but rather to deliver the required value to the customer and the stakeholders in an effective and efficient manner. If that is true, why care about the second miracle? Why not simply deliver the answer and move on? Removing the first miracle helps ensure we are solving the right problem. Removing the second miracle helps solve the problem right.
As Richard Beasley, Rolls Royce Systems Engineering Fellow, states, “Systems engineering collects and organises all the information to understand the whole problem, explores it from all angles, and then finds the most appropriate solution.” Systems engineering is a team activity. If we live behind the curtain of “then a miracle occurs,” we preclude others from understanding our reasoning, questioning our rationale, exposing alternatives, and ultimately helping us find the most appropriate solution.
This is one of the most critical but most overlooked aspects of MBSE done well. It is not simply about enhancing the clarity of the design specification by moving from words to defined notations. It is about improving communication – with fellow systems engineers, with domain specialists, with customers and users – during the design process so that we can identify concerns, make trades explicit, consider risks, and make a fully informed decision as we determine the path forward. Systems engineering is not about the expertise of the individual in isolation. It is about the wisdom of the team. As renowned computer scientist Sandy Pentland wrote, “Collective intelligence of groups and communities has little to do with intelligence of individual members and much more to do with the connections between them.”
The risks and rewards of exposing our thinking
It is scary to expose ourselves in this way. Most people fear making errors in public and having others point out their mistakes. The reality is that we all will make mistakes. If I make an error, overlook an impact, or simply fail to consider an alternative, I would much rather my teammates help me identify it early when it can be addressed in an effective and cost-efficient manner. I would much prefer to catch the issue early in design rather than to ultimately see my system fail in the field. This is only possible to the degree that we draw back the curtain and expose our thinking. As Jeff Sili pointed out in his blog “Mightier than the Pen,” in the same way that MBCD exposes necessary richness during conceptual development, MBSE helps us expose and share this thinking throughout the journey to remove the second miracle from systems engineering.
Software engineering learned long ago that the most expensive and least effective manner of dealing with software defects is classical test. We can focus on ways to improve and automate testing, but focusing solely on test is costly and imperfect. The far better route is injecting reviews throughout the process – design reviews, code reviews, and more. In the same way, good system verification enabled by exposing our thinking begins early in the design phase before we embed defects in our requirements, our architecture, and our system.
Model-based techniques are key to modern systems engineering. They provide analytic power necessary to assess impacts, explore the design envelope, and validate our systems concepts early. They provide essential tools to deal with increasing complexity in our requirements, our technologies, and our systems. More than that, MBCD and MBSE are critical communication tools that help us better represent our ideas – not only in the final design specification but throughout the systems engineering process so that we can commit with confidence. However, it takes more than just applying model-based approaches. It requires a willingness to expose our thinking to review and critique. It requires us to show our work and eliminate the crutch of “Then a miracle occurs.”
